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ABSTRACT 
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Context 


The Larch Family of Languages 


= The Larch Project is developing tools and techniques intended to aid in the productive use of 
formal specifications of systems containing computer programs. Many of its premises and goals are 
discussed in [Guttag, Horning, and Wing 82]. 

We view a system as consisting of a state and mechanisms for changing and extracting information 
from that state. We choose to define the information contained in the state without reference to 
either how that information was created or how it will be used. Our specifications consist of two 
parts. In one, we specify the properties of values that may appear in system states, and in the second, 
the program modules that deal with those states. 

A major component of the Larch Project is a family of specification languages. Each Larch 
language has a component particular to a specific programming language and another component 
common to all programming languages. We call the former interface languages, and the latter the 
shared language. 

We use the interface languages to specify program modules. Specifications of the interface that 
one module presents to other modules often rely on notions specific to the programming language, 
e.g., its denotable values or its exception handling mechanisms. Each interface language deals with 
what can be observed about the behavior of programs written in a specific programming language. 
Its simplicity or complexity is a direct consequence of the simplicity or complexity of the observable 
state and state transformations of that programming language. 

The shared language is algebraic. It is used to specify abstractions that are independent of both 
the program state and the programming language. The operators defined by an algebraic specification 
appear in specifications written in the interface languages, and in reasoning about such specifications, 
but they are not directly available to users of programs. The role of shared language specifications 
is similar to that of abstract models in some other styles of specification. 

Some important aspects of the Larch family of specification languages are: 

Composability of specifications. We emphasize the incremental construction of specifications 
from other specifications. The importance of such mechanisms is discussed in [Burstall 
and Goguen 77]. Larch has mechanisms for building upon and decomposing 
specifications as well as for combining specifications. 

Emphasis on presentation. Reading specifications is an important activity. To assist in this 
process, we use composition mechanisms defined as operations on specifications, rather 
than on theories or models. 

Interactive and integrated with tools. The Larch languages are designed for interactive use. 
They are intended to facilitate the interactive construction and incremental checking of 
specifications. The decision to rely heavily on support tools has influenced our language 
design in many ways. 


Semantic checking. It is all too easy to write specifications with suprising implications. We 
would like many such specifications to be detectably ill-formed. Extensive checking 
while specifications are being constructed is an important aspect of our approach. Larch 
was designed to be used with a powerful theorem prover for semantic checking to 
supplement the syntactic checks commonly defined for specification languages. We 
have been influenced here by our experience with Affirm [Musser 80]. 

Programming language dependencies localized. We feel that it is important to incorporate many 
programming-language-dependent features into our specification languages, but to 
isolate this aspect of specifications as much as possible. This prompted us to design a 
single shared language that could be incorporated into different interface languages in 
a uniform way. 

Shared language based on equations. The shared language has a simple semantic basis taken 
from algebra. Because of the emphasis on composability, checkability and interaction, 
however, it differs substantially from the “algebraic” specification languages we have 
used in the past. ’ 

Interface languages based on predicate calculus. Each interface language is based on assertions 
written in typed first-order predicate calculus with equality, and incorporates 
programming-language-specific features to deal with constructs such as side effects, 
exception handling, and iterators. Equality over terms is defined in the shared language; 
this provides the link between the two parts of a specification. 


Status and Plans 


We are still in the early phases of the Larch project. In addition to the work described in this 
report, interface languages for CLU and Mesa have been designed. [Wing 83] contains a detailed 
description of the semantics of the CLU interface language. The Mesa interface language has not 
been documented, but we have used it, in conjunction with the shared language, to specify the 
program level interface to the Cypress data base system. This is the largest specification we have 
attempted. 

A primitive checker for the Shared Language has been implemented [Kownacki 83]. In addition 
to parsing specifications, this program checks various context sensitive constraints and provides 
mechanisms for “expanding” assumptions, importations, and inclusions. This checker is an interim 
tool. We designed our specification language in tandem with an editing and viewing tool. Many 
language design decisions were influenced by the presumption that specifications would be produced 
and read interactively using this tool. A first design is complete (Zachary 83], but implementation 
has yet to begin. 

We are in the process of implementing term rewriting software [Forgaard 83], [Lescanne 83] that 
we hope will provide much of the theorem-proving capability needed for analyzing specifications. 
The definition of the Larch Shared Language calls for a number of checks for which there can be 
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no effective procedure. We have what we believe are useful procedures, based on sufficient or 
necessary (but not both) conditions, for some of these checks, e.g., consistency. We are working on 
procedures for the others, e.g., checking constrains clauses. This is a difficult task. Diagnostics present 
a particularly vexing problem: How should relatively complicated theorem-proving precedures report 
problems to users who are not familiar with either their internal structure or the theory underlying 
them? 

It is always difficult to evaluate a language that has not been extensively used. The Larch Shared 
Language is especially hard to evaluate because it has been designed for use in an environment that 
we have not yet built. In addition to the specification of Cypress, we have written a number of small 
specifications. On the whole, we were pleased by the ease of constructing these specifications in 
Larch, and with the specifications themselves. While constructing them, we uncovered several errors 
by inspection; we are encouraged that most of these errors would have been detected automatically 
by the checks called for in the language definition. It will be some time, however, before we can 
draw any strong conclusions about the potential utility of Larch in software development. 
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An Introduction to the Larch Shared Language 


1. Simple Algebraic Specifications 


Most of the constructs in the Larch Shared Language are designed to assist in structuring 
specifications, for both reading and writing. The ‘rait is our basic module of specification. Consider 
the following specification for tables that store values in indexed places: 

TableSpec: trait 
introduces 
new: — Table 
add: Table, Index, Val — Table 
#€E#: Index, Table — Bool 
eval: Table, Index -» Val 
isEmpty: Table —> Bool 
size: Table —» Card 
constrains new, add, €, eval, isEmpty, size so that 
for all [ ind, indl: Index, val: Val, t: Table } 


eval(add(1, ind, val) , ind! ) = if ind = ind/ then val else eval(t, ind!) 
ind € new = false 

ind € add(t, ind!, val) = (ind = ind!) | (ind € A) 

size(new) = 0 

size(add(1, ind, val)) = if ind € ¢ then size(d else size() + 1 
isEmpty() = (size() = 0) 

This example is similar to a conventional algebraic specification in the style of [Guttag and 
Horning 80] and [Musser 80]. The part of the specification following introduces declares a set of 
operators (function identifiers), each with its signature (the sorts of its domain and range). These 
signatures are used to sort-check ferms (expressions) in much the same way as function calls are 
type-checked in programming languages. The remainder of the specification constrains the operators 
by writing equations that relate sort-correct terms containing them. 

There are two things (aside from syntactic amenities) that distinguish this specification from a 
specification written in our earlier algebraic specification languages: 

A name, TableSpec, is associated with the trait itself. 
The axioms are preceded by a constrains list. 

The name of a trait is logically unrelated to any of the names appearing within it. In particular, 
we do not use sort identifiers to name units of specification. A trait need not correspond to a single 
“abstract data type,” and often does not. 

The constrains list contains all of the operators that the immediately following axioms are 
intended to constrain. It is the responsibility of a specification checker to ensure that the specification 
conforms to this intent. The constrained operators will generally be a proper subset of the operators 
appearing in the axioms. In this example the constrains list informs us that the axioms are not to 
put any constraints on the properties of if then else, false, 0, 1, +. |, and =, despite their occurrence 
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in the axioms. The judicious use of constrains lists is an important step in modularizing specifications. 
We associate a theory with every trait. A theory is a set of well-formed formulas (wff's) of typed 
first-order predicate calculus with equations as atomic formulas. 
The theory, call it Th, associated with a trait written in the Larch Shared Langtiage is defined 
by: 
. Axioms: Each equation, universally quantified by the variable declarations of the containing 
constrains clause, is in Th. 
Inequation: ~(true = false) is in Th. All other inequations in Th are derivable from this one 
and the meaning of =. 
First-order predicate calculus with equality: Th contains the axioms of conventional typed 
first-order predicate calculus with equality and is closed under its rules of inference. 
The equations and inequations in Th are derivable from the presence of axioms in the trait—never 
from their absence. Th is deliberately small, because it is important to prove theorems before a 
specification is complete, and we wanted to limit the circumstances under which the addition of new 
operators and equations could invalidate previously proved theorems. Had we chosen to take the 
theory associated with either the initial or final interpretation of a set of equations (as in [ADJ 78] 
and [Wand 79]), this monotonicity property would have been lost. 


2. Getting Richer Theories 


While the relatively small theory described above is often a useful one to associate with a set of 
axioms, there are times when a larger theory is needed, e.g., when specifying an “abstract data type.” 
Generated by and partitioned by give different ways of specifying larger theories. 

Section 1 does not include an induction schema. This is an appropriate limitation when the set 
of generators for a sort is incomplete. Saying that sort S is generated by a set of operators, Ops, 
asserts that each term of sort S is equal to a term whose outermost operator is in Ops. One might, 
for example, say that the natural numbers are generated by 0 and successor and the integers generated 
by 0, successor, and predecessor. Generated by adds an inductive rule of inference. 

This inductive rule and the clause Table generated by [ new, add ] can be used to derive theorems 
such as 

Vu: Table [ (¢ = new) | (Sind: Index [ ind € 1] )], 
that would otherwise not be in the theory. 
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Section 1 allows equations to be derived only by direct equational substitution, not by the 
absence of inequations. This is an appropriate limitation when the set of observers for a sort is 
incomplete. Saying that sort S is partitioned by a set of operators, Ops, asserts that f two terms of 
sort S are unequal, a difference can be observed using an operator in Ops. Thereforé, they must be 
equal if they cannot be distinguished using any of the operators in Ops. This rule of inference adds 
new equations to the theory associated with a trait, thus reducing the number of equivalence classes 
in the equality relation. 

This rule and the clause Table partitioned by [ €, eval ] can be used to derive theorems such as 

add(add(¢, ind, v), indI, v) = add(add(t, indl, v), ind, v), 
that would otherwise not be in the theory. 


3. Combining Independent Traits 


Our example contains a number of totally unconstrained operators, e.g., false and +. Such traits 
are not very useful. The most straightforward thing to do would be to augment the specification with 
additional clauses dealing with these operators. One way to do this is by trait importation. We might 
add to trait TableSpec: 

imports Cardinal, Boolean 

The theory associated with the importing trait is the theory associated with the union of all of 
the introduces and constrains clauses of the trait body and the imported traits. 

Importation is used both to structure specifications to make them easier to read and to introduce 
extra checking. Operators appearing in imported traits may not be constrained in either the importing 
trait or any other imported trait. This guarantees that imported traits don’t “interfere” with one 
another in unexpected ways. [.e., it guarantees that the theory associated with a trait is a conservative 
extension of each of the theories associated with its imported traits. (An extension, Thl, of a theory, 
Th2, is conservative if and only if every wff of the language of Th2 which is in Th] is also in Th2.) 
Each imported trait can, therefore, be fully understood independently of the context into which it is 
imported. 

As a syntactic amenity, trait Boolean is automatically imported into all other traits. 
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4. Combining Interacting Traits 


While the modularity imposed by importation is often helpful, it can sometimes be too restrictive. 
It is often convenient to combine several traits dealing with different aspects of the’ Same operator. 
This is common when specifying something that is not easily thought of as an abstract data type. 
Trait inclusion involves the same union of clauses as trait importation, but allows the included 
operators to be further constrained. Consider, for example: 
Reflexive: trait 


introduces #.rel#: T, T -> Bool 
constrains .rel so that for all [ ¢: T ] 


t rel ¢ = true 
Symmetric: trait 
introduces #.rel#: T, T —> Bool 
constrains .rel so that for all [ ¢/, 12: T ] 
ud sel (2 = 12 rel tl 
Transitive: trait 
introduces #.rel#: T, T — Bool 
ins .rel so that for all [ ¢/, (2, 13: T ] 
(C(t rel ¢2) & (12 .rel 13)) => (t/ .rel 73)) = true 
Equivalence: trait 
includes Reflexive, Symmetric, Transitive 
Equivalence has the same associated theory as the less structured trait 
Equivalencel: trait 


introduces #.rel#: T, T -» Bool 
constrains .rel so that for all [ /, (2, 13: T ] 


ul rel t/ = true 
a sel (2 = 12 .rel t/ 
(((t .rel 12) & (42 .rel (3)) => (1/ .rel 13)) = true 
Any legal trait importation may be replaced by trait inclusion without either making the trait 
illegal or changing the associated theory. It does involve the sacrifice of the checking that ensures 
that the imported traits may be understood independently of the context in which they are used. We 
use importation when we can incorporate a theory unchanged, inclusion when we cannot. 


5. Renaming and Exclusion 


The specification of Equivalence in the previous section relied heavily on the coincidental use 
of the operator .rel and the sort identifier T in three separate traits. In the absence of such happy 
coincidences, renaming can force names to coincide, keep them from coinciding, or simply replace 
them with more suitable names. 
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The phrase 
Tr with [ x for y ] 
stands for the trait Tr with every occurrence of y (which must be either a sort or opegator identifier) 
replaced by x. Notice that if y is a sort identifier this renaming may change the signatures associated 
with some operators. 
« Occasionally we wish to eliminate an operator altogether. The phrase 
Tr without [ op ] 
stands for the trait Tr without the declaration of op and without each axiom, generated by, and 
partitioned by in which op appears. We use without to remove an operator either so that we can later 
add another operator with the same name and signature but different properties or merely because 
it is superfluous and we want to spare readers the bother of looking at it. 
If TableSpec contains the generated by and partitioned by of section 2, the specification 
ArraySpec: trait 
imports IntegerSpec 
includes TableSpec without [ size ] 


with [ defined for #€ #, assign for add, read for eval, 
Array for Table, Integer for Index ] 


stands for 
ArraySpec: trait 
imports IntegerSpec 
introduces 


new: -—> Array 
-assign: Array, Integer, Val —> Array 
defined: Integer, Array — Bool 
read: Array, Integer -» Val 
isEmpty: Array — Bool 
constrains new, assign, defined, read, isEmpty so that 
Array generated by [ new, assign ] 


Array partitioned by [ defined, read ] 
for all [ ind, ind]: Integer, val: Val, t: Array | 


read(assign(t, ind, val), indl) = 
if ind = ind] then val else read(t, ind!) 
defined(ind, new) = false 
defined(ind/, assign(t, ind, val)) = ((ind = indl) | defined(ind!/, 1) 
Notice that in this specification isEmpty is totally unconstrained. In section 7 we discuss a 
checking mechanism that would call the lack of constraints on isEmpty to the specifier’s attention. 
This would, presumably, provoke him either to add the axioms 
isEmpty(new) = true 
isEmpty(assign(, ind, val)) = false 
to his specification, or to add isEmpty to the without clause. 
The use of without rather than some sort of hiding mechanism (as in [Burstall and Goguen 81)) 
may thus involve some extra work for the specifier. In return for this work, users of the specification 
are spared having to deal with the “hidden” operators, ¢.g., in proofs that use the specification. This 
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is consistent with our belief that specifiers should be encouraged to do things that will make life 
easier for users of their specifications. 

The definition of without should make it clear that we are indeed operating on (pe text of traits 
(presentations) rather than on their associated theories. Consider adding these isEmpty axioms to 
TableSpec to form another trait, TableSpecl. TableSpec and TableSpec] have the same associated 
theories, but 

TableSpec without size 
and 
TableSpecl without size 
have rather different associated theories—in the latter, isEmpty is fully defined. 

A final point raised by the examples of this section is the importance of distinguishing between 
the history of a specification (how it was constructed) and the structure presented to a reader. A 
reader familiar with TableSpec might prefer to read the first version of ArraySpec; others might find 
it distracting to have to understand the more general structure before understanding ArraySpec. 


6. Assumptions 


We often construct fairly general specifications that we anticipate will later be specialized in a 
variety of ways. Consider, for example, 
MultiSetSpec: trait 

introduces 
{}: — MultiSet 
insert: MultiSet, Elem — MultiSet 
delete: MultiSet, Elem -> MultiSet 
#€E#: MultiSet, Elem —> Bool 

constrains {}, insert, delete, € so that 
MultiSet generated by [ {}, insert ] 
MultiSet partitioned by [ delete, € ] 
for all [ m: MultiSet, e, e/: Elem ] 


e € {} = false 
e € insert(m, e/) = (e = e/) | (e € m) 
delete({}, e) = {} 
delete(insert(m, e), e/) = 
if e = e/ then m else insert(delete(m, e/), e) 
We might specialize this to IntMultiSet by renaming Elem to Integer and including it in a trait 
in which operators dealing with Integer are specified, e.g., 
IntMultiSet: trait 
imports IntegerSpec 
includes MultiSetSpec with [ Integer for Elem ] 
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The interactions between MultiSetSpec and IntegerSpec are very limited. Nothing in 
MultiSetSpec places any constraints on the meaning of the operators that occur in IntegerSpec, ¢.g., 
0, +, and <. Consider, however, extending MultiSetSpec to MultiSetSpecl by addtmg an operator 
rangeCount, 

MultiSetSpecl: trait 
imports MultiSetSpec, Cardinal 
introduces 


rangeCount: MultiSet, Elem, Elem —> Integer 
#<#: Elem, Elem - Bool 
constrains rangeCount so that for all [ e/, e2, e3: Elem, m: MultiSet ] 


rangeCount({}, e/, e2) = 0 
rangeCount(insert(m, e3), e/, e2) = 
rangeCount(n, el, e2) + (if (el < e3) & (e3 < e2) then 1 else 0) 
MultiSetSpecl places no constraints on the < operator. Suppose, however, that this is not what 
we intend. We might have definite ideas about the properties that < must have in any specialization, 
e.g., that it should define a total ordering. We could specify such a restriction by adding to 
MultiSetSpec] the assumption (Ordered is defined in the Handbook section, on page 36): 
assumes Ordered with [ Elem for T ] 
In constructing the theory associated with MultiSetSpecl, the assumption would be treated as if 
Ordered with [ Elem for T ] had been included. This could be used to derive various properties of 
MultiSetSpecl, e.g., that rangeCount is monotonic in its last argument. 
Whenever the augmented MultiSetSpecl is imported or included in another trait, however, the 
assumption will have to be be discharged. In 
IntMultiSetl: trait 
includes MultiSetSpec1 with [ Integer for Elem ] 
imports IntegerSpec 
this would amount to showing that the (renamed) theory associated with Ordered is a subset of the 
theory associated with IntegerSpec. Often, the assumptions of a trait are used to discharge the 
assumptions of traits it imports or includes. 


7. Consequences 


We have now looked at those parts of the Larch Shared Language that determine the theory 
associated with a valid trait. That subset of the language contains some checkable redundancy; e.g., 
assumptions are checked when a trait is included or imported, and constrains lists are checked against 
the axioms associated with them. We now turn to a part of the language whose only purpose is to 
introduce checkable redundancy, in the form of assertions about the theory associated with a trait. 

There are two kinds of consequence assertions: 

That the theory associated with a trait contains another theory. 
That the theory associated with a trait “adequately” defines a set of operators in terms of 
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other operators. 

The first kind of assertion is made using implies. Consider, for example, adding to the augmented 

MultiSetSpecl, 
implies for all {m: MultiSet, e/, e2, e3: Elem] 
(e2 < e3) =» (rangeCount(m, e/, e2) < rangeCount(m, el, e3)) 

Implies can be used to indicate intended consequences of a specification, both for checking and 
to increase the reader’s insight. The theory to be implied can be specified using the full power of 
the language, e.g., by using generated by and partitioned by, or by referring to traits defined elsewhere. 

The second kind of assertion is made using converts [ Ops ]. This asserts that each term is 
provably equal to a term that does not contain operators in Ops. (We do not require this for terms 
containing variables of sorts appearing in generated by clauses.) Converts is used to say that the 
specification adequately defines a collection of operators. 

A common problem with axiomatic systems is deciding whether there are “enough” axioms. 
Converts provides a way of making a checkable statement about the adequacy of a set of axioms. 
Consider, for example, adding to TableSpec: 

converts [ isEmpty ]. 
This says that each term containing isEmpty, such as isEmpty(new) or isEmpty(add(new), ind, vai)), 
is equal to another term that does not contain isEmpty. 

Now consider adding to TableSpec the stronger assertion: 

converts [ isEmpty, eval ]. 
Terms containing subterms of the form eval(new, ind) are not convertible to terms that do not contain 
eval, so an error message of the form 

eval(new, ind) not convertible 
would be generated. This would present a problem if we did not wish to add an axiom to resolve 
this incompleteness. We therefore provide a mechanism to allow specifiers to indicate that the 
unconvertibility of certain terms is acceptable. If TableSpec were modifed to include 

exempts for all [ ind: Index ] eval(new, ind) | 
the checking associated with the converts would now require that the theory associated with TableSpec 
must contain either 

an equation, t = tl, where tl has no occurrences of isEmpty or eval, or 

an equation t’ = tl, where ¢’ is a subterm of t, and tl is an instantiation of eval(new, ind). 

This checking ensures that each term containing operators in the converts list is either defined 
by the axioms (in terms of operators not in the list) or explicitly exempted. One use of converts is 
to allow the specification checker to notice unintended effects of without. As suggested in section 6, 
the failure of ArraySpec to fulfill the converts inherited from TableSpec would trigger error messages 
of the form: 

isEmpty(new) not convertible 
isEmpty(assign(t, ind, val)) not convertible. 
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8. IfThenElse and Equality 


In our examples we made use of some apparently unconstrained operators: if then else and =, 
with a variety of signatures. In fact, the appearance of these operators leads f the implicit 
incorporation of the traits IfThenElse and Equality. 

Whenever a term of the form if b then tl else t2 occurs in a trait we replace the mixfix symbol 
if then else by the prefix symbol ifThenElse. If tl and t2 are of the same sort, Tl, we also import 
the trait IfThenElse with [ T1 for T ] into the enclosing trait. 

Whenever a term of the form tl = t2 occurs in a trait, if tl and t2 are of the same sort, Tl, we 
append the trait Equality with [ Tl for T ] to the consequences of the enclosing trait. 

Specifications of these traits are: 

IfThenElse: trait 
; introduces ifThenElse: Bool, T, T — T 
constrains ifThenElse so that for all [ ¢/, 12: T ] 
ifThenElse(true, ¢/, (2) = t/ 
ifThenElse(false, ¢/, 12) = 12 
implies converts [ ifThenElse ] 
Equality: trait 
includes Equivalence with [ = for .rel ] 
constrains = so that T partitioned by [ = ]. 


9. Some Further Examples 


The following series of examples is adapted from the Handbook chapter. We include them here 
to illustrate some ways in which the facilities introduced above can be used. In reading these 
specifications, keep in mind that they are not themselves ends, but rather means to write interface 
specifications. 

Our first example is an abstraction of those data structures that “contain” elements, e.g., Set, 
Bag, Queue, Stack. We have found it useful both as a starting point for specifications of various 
kinds of containers, and as an assumption for generic operations. The crucial part of the trait is the 
generated by. It indicates that any term of sort C is equal to some term in which new and insert are 
the only operators with range C—even if this trait is included in one that introduces additional 
operators that return values of sort C. This means that any theorems proved by induction over new 
and insert will remain valid. 

Container: trait % C’s contain E's 
introduces 
new: ~C 


insert: C, E -> C 
constrains C so that C generated by [ new, insert ] 


The next example incorporates Container as an assumption. Notice that it constrains new and 
insert as well as the operator it introduces, isEmpty. The converts indicates that this trait contains 
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enough axioms to adequately specify isEmpty. Because of the generated by, this can be proved by 
induction over terms of sort C, using new as the basis and insert(c, e) in the induction step. 
IsEmpty: trait 
assumes Container 
introduces isEmpty: C — Bool 
constrains isEmpty, new, insert so that for all [ c: C, e: E] 
isEmpty(new) = true 
isEmpty(insert(c, e)) = false 
implies converts { isEmpty ] 

The next two examples assume Container. The exempts indicate that should these traits be 
included into a trait that claims the convertibility of next or rest, that trait needn’t convert the terms 
next(new) or rest(new). 

Next: trait 


assumes Container 
introduces next: C — E 
constrains next, insert so that for all [ e: E } 


next(insert(new, e)) = e 

exempts next(new) 

Rest: trait 

assumes Container 

introduces rest: C —> C 

constrains rest, insert so that for all [ e: E ] 
rest(insert(new, e)) = new 

exempts rest(new) 

The next example specifies properties common to various data structures such as stacks, queues, 
priority queues, sequences, and vectors. It augments Container by combining it with IsEmpty, Next, 
and Rest. The partitioned by indicates that next, rest, and isEmpty are sufficient to define equality 
over terms of sort C. Since we have little information about next and rest, the partitioned by does 
not yet add much to the associated theory. 

Enumerable: trait 


imports IsEmpty, Next, Rest 
includes Container 
constrains C so that C partitioned by [ next, rest, isEmpty ] 
The next example specializes Enumerable by further constraining next, rest, and insert. Sufficient 
axioms are given to convert next and rest. The axioms that convert isEmpty are inherited from the 
trait Enumerable, which inherited them from the trait IsEmpty. 
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PriorityQueue: trait 
assumes TotalOrder with [ E for T ] 
includes Enumerable 
constrains next, rest, insert so that for all [ g: C, e: E] 


next(insert(q, ¢)) = 
if isEmpty(g) then e 
else if next(q) < e then next(q) else ¢ 
rest(insert(q, ¢)) = 
if isEmpty(g) then new 
else if next(q) < e then insert(rest(q), e) else 
implies converts [ next, rest, isEmpty ] 

In a trait, such as PriorityQueue, that defines an “abstract data type” there will generally be a 
distinguished sort (C in this case) corresponding to the “type of interest” of [Guttag 75] or “data 
sort” of [Burstall and Goguen 81]. In such traits, it is usually possible to partition the operators whose 
range is the distinguished sort into “generators,” those operators which the sort is generated by, and 
“extensions,” which can be converted into generators. Operators whose domain includes the 
distinguished sort and whose range is some other sort are called “observers.” Observers are usually 
convertible, and the sort is usually partitioned by one or more subsets of the observers and extensions. 

The next example illustrates a specialization of Container that does not satisfy Enumerable. It 
augments Container by combining it with IsEmpty and Cardinal, and introducing two new operators. 
Notice that we include Container, because we intend to constrain operators inherited from it, but 
import IsEmpty and Cardinal, because we do not intend to constrain any operator inherited from 
them. Constrains C is a shorthand for a constrains clause listing all the operators whose signature 
includes C. The partitioned by indicates that count alone is sufficient to distinguish unequal terms of 
sort C. Converts [ isEmpty, count, delete } is a stronger assertion than the combination of an explicit 
converts { count, delete ] with the inherited converts [ isEmpty ]. 

MultiSet: trait 
assumes Equality with [ Elem for T ] 
imports IsEmpty, Cardinal 
includes Container with [ empty for new ] 
introduces count: Elem, C -> Bool 
delete: Elem, C > C 
constrains C so that 
C partitioned by [ count ] 
for all [ c: C, el, e2: E } 


count(empty, e/) = 0 
count(insert(c, e/), e2) = count(c, e2) + (if e/ = e2 then | else 0) 
delete{empty, e/) = empty 
delete{insert(c, e/), e2) = 
if e/ = e2 then c else insert(delete(c, e2), e/) 
implies converts [ isEmpty, count, delete ] 
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The next example specifies a generic operator. It uses Enumerable as an assumption to delimit 
the applicability of this operator to containers for which it is possible to enumerate the contained 
elements, (To understand why we assume Enumerable rather than Container, imaginegdefining extOp 
far a MultiSet.) The exempts indictates that we do not intend to fully define the meanjng of applying 
extOp to containers of unequal size. Notice that elemOp is totally unconstrained in this trait. This 
prevents us from having many interesting implications to state at this stage. 

PairwiseExtension: trait 
assumes Enumerable 
introduces 


elemOp: E,.E~E 
extOp: C,C +> C 
constrains extOp so that for all [ c/, c2: C, e/, e2: E] 


extOp(new, new) = new 
extOp(insert(c/, e/), insert(c2, e2)) = insert(extOp(c/, c2), elemOp(e/, e2)) 
implies converts [ extOp ] 
exempts for all [ c: C, e: E ] 
extOp(new, insert(c, e)), 
extOp(insert(c, e), new) 
Now we specialize PairwiseExtension by binding elemOp to + over Cardinals: 
PairwisePlus: trait 
assumes Enumerable 
imports Cardinal 
includes PairwiseExtension with [ #+# for elemOp, # +4 for extOp, Card for E ] 
implies Commutative with [ #+# for O, C for T ] 


The validity of the implication that + for sort C is commutative stems from the replacement of 
elemOp by + for sort Card, whose constraints (in trait Cardinal) imply its commutativity. 
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Larch Shared Language Reference Manual 


0. Structure of Manual 


In section 1 we present a grammar for the kernel subset of the Larch Shared Language. 

In section 2 we define the context sensitive checking and the theory associated with each 
specification written in the kernel subset. 

In section 3 we extend the kernel subset by introducing mechanisms for specifying intended 
consequences of a specification written in the kernel subset. 

In sections 4-10 we define successive extensions of the language. We modify the grammar to 
introduce additional aspects of the language and describe any additional context sensitive checking 
required. We also provide a translation from the newly extended language to the previously defined 
subset. The result of this translation is subjected to all the applicable checking. The theory associated 
with any specification written in the full language is the same as the theory associated with its 
translation. 

Section 11 describes additional checks, defined in terms of the theories associated with traits, 
that are associated with various language features. To be legal, a specification and each of the parts 
from which it is built must satisfy these checks as well as the context sensitive checks described 
earlier. 

Finally, section 12 collects the reference grammar for the entire language. 
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1. Kernel Syntax 
1.1. Syntactic conventions 


| 


alternative separator 


{e} e is optional 

e* zero of more e’s 

e*, zero or more e’s, separated by commas 

e+ one or more e’s 

alpha alpha is a nonterminal symbol 

alpha alpha is a terminal symbol 

() parentheses as terminal symbols 

(e) parentheses for grouping syntactic expressions 


1.2. Grammar 


trait 
traitBody 


simpleTrait :: 


opPart 
opDel 
Signature 
domain 
range 
propPart 
props 


generators :: 


partitions 
bylist 
sortedOp 
axioms 
varDel 
equation 
term 
opid 
opForm 
opSym 
traitid 
sortid 
varld 


Comments start with % and terminate with end of line. They may appear after any token. 


il 


traitid : trait traitBoady 
simpleT rait 

{opPart} propPart* 
introduces opDc/* 
opid : signature 
domain -— range 
sortid*, 

sortid 

asserts props 


:!=generators* partitions* axioms* 


sortid generated bylist*, 


= sortid partitioned bylist*, 


by [ sortedOp”*, ] 

opDe!l 

for all [ varDc/*, | equation* 
varid*, : sortid 

term = term 

sortedOp { '( term*, ’) } | varid 
alphaNumeric + | opForm 

{ # } opSym ( # opSym )* { # } 
specialChar+ | . alphaNumeric + 
alphaNumeric + 


= alphaNumeric + 
= alphaNumeric + 
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2. Simple Traits 
2/1. Context sensitive checking 


simpleTrait: 
= The sets of varid’s, sortid’s and opio’s appearing in a trait must be disjoint. 
* ‘Every sortid appearing anywhere in a simpleTrait must appear in its opPart. 
Every sortedOp appearing anywhere in a simpleTrait must appear in its opPart. 


opDel: 
Each opForm must have the same number of #’s as the number of occurrences of sortid’s in 


the domain. 


generators: 

The range of each sortedOp must be the sortid of the generators. 

At least one sortedOp in each bylist must have a domain in which the sortid of the generators 
does not occur. 


partitions: 

The domain of each sortedOp must include the sortid of the partitions. 

The range of at least one sortedOp in each bylist must be different from the sortid of the 
partitions. 


axioms: 
Each varid used in a term must appear in exactly one varDcl. 
No varid may occur more than once in [ varDci*, ]. 


equation: 
The sorts of both term’s must be the same, where 
The sort of a term of the form sortedOp { ’( term*, ’) } is the range of the sortedOp. 
The sort of a term of the form varid is the sortid of the varDc/ in which the varid is declared. 


term: 
In sortedOp { *( term*, ’) } the domain of the sortedOp must be the sequence of the sorts of 
the terms in term”, . 
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2.2, Associated theory 


We associate a theory with each trait. This section defines the theory associated with a 
simpleTrait. 
~ A theory is a subset of the language: 
wif ::= term = term 


| “propositional formula" 
| “first order quantified (with sorts) formula” 


We adopt the conventional meanings of the equality symbol (=), the propositional connectives 
(&, |, ~, =>, ...), and the quantifiers (V and 3). 
The subset of wff that is the theory, call it Th, associated with a simpleTrait is defined by: 
Axioms: Each equation, universally quantified by the varDc/'s of its containing axioms, is in 
Th. 
Inequation: ~(true:—>Bool = false:—>Bool) is in Th. 
First order predicate calculus with equality: Th contains the axioms of conventional typed 
first-order predicate calculus with equality and is closed under its rules of inference. 
Induction: If the trait has a generators with sortid S and a bylist by [op}, ..., Op,], and P(s) 
is a wff with a free variable, s, of sort S, Th contains the wff 
V[s: S] P(s) 
if for each op; in [op), ... , Op,] 
Qi => P(op;(x, .... x,)) is in Th, where 
k is the arity of opi, 
the x;’s are variables that do not appear free in P, and 
Q; is the conjunction of P(x;), for each j such that the j* argument of op; 


is of sort S. 
Reduction: If the trait has a partitions with sortid S and a bylist by [op}, .... OPal, Th contains 
the wff 
V[si, s2: S] (Q => 81 = 89) 
where Q is the conjunction, for each op; in [op}, . .. , Op,] and each j such that the j* 


argument of op; is of sort S, of 

Vixi: Si... . xk: Sy] (Subst(op;, j, t) = Subst(opi, j, tz)), where 
S}, ..., Sy is the domain of op;, and 
Subst(op, j, t) is op(xi, . . . , x) with t substituted for ;. 
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3. Consequences and Exemptions 


Exempts and consequences affect only the checking (see section 11.5) and do not affect the 
theory. We add to the grammar the productions: 


trait i= traitid : trait traitBody {consequences} {exempts} 
consequences ::= implies conseqProps {converts} 

conseqProps i= props 

converts :!= converts conversion", 

conversion ::= [ sortedOp”*, ] 

exempts = exempts exemptTerms* 

exemptTerms = { for all [ varDc/*, ] } term*, 


3.1. Context sensitive checking 


conseqProps: 
If the props of the conseqProps is appended to the propPart of the containing trait, the 
resulting trait must satisfy the checks of section 2. 


exempts: 
Each term must satisfy the checks of section 2.1. 


4. Constrains Clauses 


Constrains clauses affect only the checking (see section 11.4), not the theory. We add to the 
grammar the productions: 
propPart i:== ( asserts | constrains ) props 
constrains :!= constrains ( sortid | sortedOp*, ) so that 


4.1. Translation 


constrains: 
Replace the constrains by asserts. 
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5. Implicit Signatures and Partial OpForms 


In the kernel language each sortedOp is an opDci. Here we relax this restriction to allow 
omitted and partial signatures and omitted #’s. We add to the grammar the producfion: 
sdrtedOp i= opld { — range } 


5:1. Context sensitive checking 


There must be a unique mapping from occurrences of sortedOp’s to opDci's of the traitBody 
such that the translation described in section 5.2. produces a legal traitBody and for each sortedOp, 
opDel pair: 

The opia’s match, i.e., 
They are the same, or 
They are both opForms and the one in the sortedOp is the same as the one in the 
opDc! with all #’s removed. 4s 
If the sortedOp includes —> range, it is the same as the range of the opDcl. 


5.2. Translation 


The checking ensures that each occurrence of a sortedOp corresponds to a unique opDci. The 
translation is simply to replace it by that opDci. 


6. Mixfix Operators 


In the language presented thus far, all operators are treated as either nullary or prefix. Here we 
relax that restriction. We replace the grammar for term by: 


term :!= secondary | if secondary then secondary else term 
secondary ::= { opSym } primary ( opSym primary )* { opSym } 
primary ::= sortedOp { *( term*, ’) } | varid | (term ’) 


6.1, Translation 


equation: 

It is necessary to resolve the grammatical ambiguity between the = connective in equations 
and the = opSym. In any equation the first occurrence of = that is not bracketed by parentheses 
or within an if then else is the equation connective, the remainder are opSyms. Parentheses can be 
used to enforce any desired parsing. 
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term: 
Translate each term of the form if b then t; else t; into a term of the form ifThenElse(b, t), t2). 


seconeny: 
- Translate each secondary containing opSym's into a primary of the form opld «1 term*, ’), 
opld is derived by replacing each primary in the secondary by #. 
term”, is the sequence of primary’s. 


primary: 
its ils oats iad te eis ase! ca jaa <ntasive it tae pamvatines tien 
primary’s of the form '( term ’). 


7. Boolean Terms as Equations 


It is convenient to use terms of sort Bool as axioms. We add to the grammar the production: 
equation ::= term 


7.1. Context sensitive checking 


The term must be of sort Bool. 


7.2. Translation 


Replace the term by the equation 
term = true 
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8. External References 


We add to the kernel grammar the productions: 
traitBody = externals simpleTrait 


externals = {assumes} {imports} {includes} 
assumes = assumes traitRef*, 

imports = imports traitRef*, 

includes := includes traitRef*, 

traitRef := traitid 

conseqProps = traitRef*, props 


8.1. Context sensitive checking 


externals: 
Recursive externa/s are not permitted; i.e., the traitid of the containing trait may not appear in 
an externails, nor in any partial translation of a traitRef in its externals. 


8.2. Translation 


The translation of a trait is derived bottom-up; i.e., before a trait with traitRefs is translated, 
each of its traitRefs is replaced by the translation of the trait labeled by that traitRef’s traitid. Let 
T be a trait whose simpleTrait is S and let E consist of the translations of the traitRef’s in T’s 
externals. The translation of T consists of: 

An opPart containing S’s opDc/s and E’s opDeis, 

A propPart* containing S’s propPart’s and E’s propPart’s, 

An exempts containing T’s exemptTerms and E’s exemptTerms, and 

A consequences containing the props of 
T’s conseqProps, 
the propParts of the translations of the traitRef’s in T’s conseqProps, and 
E’s consequences. 
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9. Modifications 
We add to the grammar the productions: 
traitRef ::= traitid {exclusion} {renaming} 
exclusion :1= without [ o/dOp*, ] 
rénaming := with [ ( sortRename | opRename )*, ] 
sdrtRename := sortid for oldSort 
oldSort = sortld 
opRename ::= opid for oldOp 
oldOp := sortedOp 


9.1. Context sensitive checking 


traitRef: 
No sortedOp may occur more than once as an o/dOp. 
No sortid may occur more than once as an o/dSort. 


Each o/dSort must appear in an opDc/ in the translation of the trait labeled by the traitid. 
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There must be a unique mapping from o/dOp’s to opDe''s of the translation of the trait labeled 


by the traitid, such that for each o/dOp, opDe! pair: 
The op/a’s match (see section 5.1), 


If the ofdOp includes domain, it is the same as the domain of the opDcl. 
If the o/dOp includes —> range, it is the same as the range of the opDcl. 


9.2. Translation 


The translation of the trait labeled by the traitid of the traitRef is modified by applying first 


the exci/usion, then the opRename’s, and finally the sortRename’s: 


For each o/dOp in the exclusion, delete each bylist, equation, and term containing the 


opDc! to which it maps and then delete all remaining occurrences of that opDcl. 


Then, simultaneously, for each opRename, replace the op/d part of each occurrence of the 


opDei to which the o/fOp maps by the opid of the opRename. 


Finally, simultaneously, for each sortRename, replace each occurrence of its o/dSort by its 


sortid. 
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10. Implicit Incorporation of Boolean, IfThenElse, and Equality 


Three traits, Boolean, IfThenElse, and Equality, are implicitly incorporated into various other 
traits to assure uniform meanings for the operators they constrain. 


10.1. Translation 


Append the traitRef Boolean to the imports of each trait except Boolean. 

Append the traitRef IffhenElse with [ Tl for T ] to the imports of each trait containing a term 
of the form if b then t; else tz in which t, and t) have the same sort, T1. 

Append the traitRef Equality with [ Tl for T ] to the traitRef* of the conseqProps of each 
trait (except Equality) containing a term of the form t; = t) in which t; and tp have the same sort, 
Tl. 


10.2. Built-in traits 


Boolean: trait 
introduces 
true: ~—> Bool 
false: —> Bool 
~#: Bool — Bool 
#&#: Bool, Bool — Bool 
#|#: Bool, Bool — Bool 
# => #: Bool, Bool — Bool 
# .equal#: Bool, Bool -> Bool 
asserts Bool generated by [ true, false } 
for all [ 5: Bool ] 


~true = false 

~false = true 

(true & 6) = b 

(false & b) = false 

(true | 5) = true 

(false | 6) = 5 

(true => 6) = b 

(false => 5) = true 

(true .equal 5) = 6 

(false .equal 6) = ~b 

implies converts [ ~, &, |, =>, .equal ] 

IfThenElse: trait 


introduces ifThenElse: Bool, T, T — T 
asserts for all [ ¢/, 12: T ] 


ifThenElse(true, t/, 12) = t 
ifThenElse(false, t/, 12) = 12 
implies converts [ ifThenElse ] 
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Equality: trait 
introduces # = #: T, T — Bool 


asserts T partitioned by [ = |] 
for all [ x, y, z: T J 


(x=x) 
(x=y) = (v=) 
((x=y) & (v=2)) => (x=2) 


11. Semantic Checking 


In addition to the syntactic constraints specified above, we require that each trait be logically 
consistent, discharge the assumptions of the traits it is built from, be a conservative extension of its 
imports, be properly constraining, and imply its consequences. 


11.1. Consistency 


A traitBody is consistent if its associated theory does not contain the equation 
true:—> Bool = false:—> Bool 


11.2. Assumptions 


Let A(T) be all of the assumes of the traits imported or included in T, and R(T) be the result 
of translating T after removing these assumes. A(T) is discharged by T if the theory associated with 
the translation of each traitRef of A(T) is a subset of the theory associated with R(T). 


11.3. Imports 


The theory associated with a trait must be a conservative extension of the theory associated with 
the translation of each traitRef in its imports; i.e., if trait T1 imports T2 and W is a wff of T2, W 
is in the theory associated with T1 if and only if it is in the theory associated with T2. 


11.4. Constraints 


A propPart is properly-constraining if it implies properties of only the operators in its constrains. 
The occurrence of a sortid in a constrains stands for the list of all sortedOp’s in the containing 
trait’s opPart whose signatures include that sortid. 

Let T be a trait and P be the propPart constrains sortedOp*, so that props. P is 
properly-constraining in the trait consisting of T plus P if and only if each wff in the theory associated 
with T plus P is also in the theory associated with T or else contains ops in sortedOp*. 

Note that, since the translation of a traitRef converts constrains to asserts, this check is performed 
only on traits in which constrains appears explicitly. 
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11.5. Consequences 


A trait implies its consequences if the theory associated with its conseqProps is a subset of 
the theory associated with the trait and the [ sortedOp*, ] in each converts: is convertible. 
Cenvertibility is defined using the theory and exempts of a trait. 
censeqProps: 

The theory associated with conseqProps must be a subset of the theory of the trait in which 
the consequences appears. The theory associated with a conseqProps is the theory associated with 
the traitbody: 

includes traitRef*, opPart asserts props 
where traitRef*, and props form the conseqProps, and opPart is the opPart of the trait in which 
the consequences appears. oS 

Note that an exc/usion, but not a renaming, can invalidate a consequence that has been locally 
checked. 


conversion: 
Let C be a conversion. For each term, t, that contains no variables of any sort appearing in a 
generators in the containing trait, the theory of the containing trait must either 
contain an equation t = u, 
where u contains no sortedOp appearing in C’s sortedOp*, or 
contain an equation t = u, 
where ¢ is a subterm of t, and u is an instantiation of a term appearing in an exempts 
of the containing trait. 


trait 
traitBody 
externals 


assumes 
imports 
includes 
traitRef 
exclusion 
renaming 
sortRename 
oldSort 
opRename 
oldOp 
sortedOp 


simpleTrait 
opPart 


opDcl 
signature 
domain 
range 
propPart 
constrains 
props 
generators 
partitions 
bylist 
axioms 
varDcl 


equation 


term 
secondary 
primary 
opld 
opForm 
opSym 
traitid 
sortid 
varld 


consequences 


conseqProps 
converts 
conversion 


exempts 
exemptTerms 


wun 
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12. Reference Grammar for The Larch Shared Language 


= traitid : trait traitBody {consequences} {exempts}. 


externals simpleTrait 
{assumes} {imports} {includes} 


assumes traitRef*, 

imports traitRef*, 

includes traitRef*, 

traitld {exciusion} {renaming} 
without [ o/dOp*, ] 

with [ ( sortRename | opRename )*, } 
sortld for oldSort 

sortid 

opid for oldOp 

sortedOp 

opDel | opid { —» range } 


= {opPart} propPart* 


winaewinw w 


witunnnnen oo 


" 


introduces opDc/* 


opid : signature 
domain — range 
sortid®, 

sortid 


( asserts | constrains ) props 


constrains ( sortid | sortedOp*, ) so that 
generators* partitions* axioms* 

sortid generated bylist*, 

sortid partitioned bylist*, 

by [ sortedOp*, ] 

for all [ varDc/*, ] equation* 

varid™, : sortid 


term { = term } 


secondary | if secondary then secondary else term 
{ opSym } primary ( opSym primary )* { opSym } 
sortedOp { ’( term*, ’) } | varid | ‘(term ’) 
alphaNumeric + | opForm 

{ # } opSym ( # opSym )* { # } 

specialChar+ | . alphaNumeric + 

alphaNumeric + 

alphaNumeric + 

alphaNumeric + 


implies conseqProps {converts} 


traitRef*, props 
converts conversion*, 
[{ sortedOp*, ] 


exempts exemptTerms* 


= { for all [ varDci*, ] } term*, 
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Towards A Larch Shared Language Handbook 


Contents 
Basic properties of single operators, including binary relations 


Associative, Commutative, Idempotent, Relation, TotalRelation, Reflexive, Irreflexive, 


Transitive, ReflexiveTransitive, Symmetric, Antisymmetric, Equivalence 
Ordering relations 


PartialOrder, TotalOrder, OrderEquivalence, OrderEquality, PartialOrder WithEquality, 
TotalOrderWithEquality, DerivedOrders, PartiallyOrdered, Ordered 


Group theory 


Leftidentity, RightIdentity, Identity, LeftInverse, RightInverse, Inverse, Abelian, Semigroup, 
Monoid, Group, AbelianSemigroup, AbelianMonoid, AbelianGroup, Distributive 


Simple numeric types 

Ordinal, Cardinal, Cardinal2 
Simple data structures 

Pair, Triple, FiniteMapping 
Container properties 


Container, Singleton, IsEmpty, Size, AdditiveSize, Join, ElementEquality, Member, 
ElemCount, Delete, Containment, Next, Rest, Remainder, Index 


Container classes 


SetBasics, BagBasics, CollectionExtensions, SetIntersection, Set, Bag, Enumerable, 
InsertionOrdered, Stack, Queue, Dequeue, Sequence, SubSequence, String, PriorityQueue 


Generic operators on containers 


CoerceContainer, Reduce, SomePass, AllPass, Sift, PairwiseExtension, PointwiseImage 
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Nonlinear structures 
BinaryTree, BasicGraph, Connectivity, Graph 
Rings, fields, and numbers 
Ring, RingWithUnit, InfixInverse, Integer, Field, Rational 
Lattices 
ExtremalBound, Semilattice, Lattice 
Enumerated data types 
Enumerated, Rainbow, Character 
Display traits 


Coordinate, Illumination, Boundary, Transform, Displayable, Picture, Contents, Component, 


ComponentCoercion, View, Display 
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Preface 


This collection of traits is a companion to the Larch Shared Language Reference Manual. We 
hope that it will serve three distinct purposes: 

Provide a set of components that can be directly incorporated into other specifications, 

Provide a set of models upon which other specifications can be based, and 

Help people to better understand the Larch Shared Language by providing a set of illustrative 
examples. 

In line with our first goal, we have tried to isolate the “smallest useful increments” of specification 
that it might be reasonable to use in other specifications. In particular, we have tried to provide traits 
that will make it convenient to specify the weak assumptions that characterize many of the more 
widely applicable specifications. This is particularly evident in the sections titled "Container 
properties” and Container classes." The traits in these sections are smaller and more numerous than 
is typical in “from scratch” specifications. This sometimes leads to a somewhat overstructured 
appearance. 

In line with our second goal, in addition to traits that we expect to be directly incorporated in 
specifications, we have included a number of traits intended primarily as patterns. The section titled 
“Generic operators on containers” contains several such traits. Because of the arity of the operators, 
it will frequently be awkward to incorporate these traits. 

In line with our third goal we have stressed familiar examples. Since they describe well-understood 
mathematical entities, many of the traits, e.g., Integer, are atypically complete. In general, we expect 
most specifications to supply constraints, rather than complete definitions. The section on Display 
traits is more typical in this respect. 

The support tools envisioned for Larch are not yet available. Transcriptions of traits in this 
chapter have been mechanically checked for some properties; some errors may not have been detected 
and some transcription errors may have crept in. They should be given the same sort of credence as 
carefully written programs that have not been checked by a compiler. 

Comments on the clarity of these specifications and on their “correctness” (relative to generally 
accepted definitions of the names used) are welcome. We also solicit contributions of further widely 
useful traits—either accompanied by specifications, or as challenges to specifiers. 


Conventions 


If a generic trait constrains only one interesting sort, the identifier T is used to denote it. 

If a trait constrains a “containing” sort and an “element” sort, the identifiers C and E are used. 

If a trait constrains a single binary operation, the infix symbo! #O# is used. 

If a trait constrains a single binary relation, the infix identifier #@# is used. 

If there would be no information in a constrains (e.g., because there is only one operator), 
asserts is used. 
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Basic Properties of Single Operators, Including Binary Relations 


Associative: trait 
introduces #O #: T, T > T 
asserts for all [ x, y, z: T ] (xO yOz=xO(027 


Commutative: trait 


introduces #O #: T, T -> Range 
asserts for all [ x, y: T ] xOy=yOx 


Idempotent: trait 
introduces op: T — T 
asserts for all [ x: T ] op(op(x)) = op(x) 


Relation: trait 

introduces #®#: T, T -> Bool 
TotalRelation: trait 

includes Relation 


asserts for all [ x, y: T ] (x® yIO® x 
Reflexive: trait 

includes Relation 

asserts for all [ x: T ] x®x 


Irreflexive: trait 


includes Relation 

asserts for all [ x: T ] ~(x ® x) 
Transitive: trait 

includes Relation 

asserts for all [ x, y, z: T } ((x ® y) & (y ® 2) => (x ® 2) 
ReflexiveTransitive: trait 

includes Reflexive, Transitive 
Symmetric: trait 

includes Relation 


asserts for all [ x, y: T ] (x® y=0 ® x) 
implies Commutative with [ ® for O, Bool for Range ] 


Antisymmetric: trait 
includes Relation 
asserts for all [ x, y: T ] ~((x ® y) & (vy ® x) 
implies Irreflexive 
Equivalence: trait 
includes ReflexiveTransitive with [ .eq for ® ], 
Symmetric with [ .eq for ® } 
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Ordering Relations 


PartialOrder: trait 

imports ReflexiveTransitive with [ < for ® ]} 
TotalOrder: trait | 

includes PartialOrder, TotalRelation with [ < for ® } 
OrderEquivalence: trait 

assumes PartialOrder 

introduces #.eq#: T, T -> Bool 


constrains .eq so that for all [ x,y: T] (x .eqy) = (x fC yN&W SK» 


implies Equivalence 
converts [ .eq ] 
OrderEquality: trait 


assumes PartialOrder 
- includes OrderEquivalence with [ = for .eq }, Equality 


PartialOrderWithEquality: trait 

includes PartialOrder, OrderEquality 
TotalOrderWithEquality: trait 

includes TotalOrder, OrderEquality 
DerivedOrders: trait 


assumes PartialOrder 
introduces 
#<#:T, T > Bool 
#>#:T, T — Bool 
#>#:T, T — Bool 
constrains < so that for all [ x, y: T ] 
constrains > so that for all [ x, y: T } 
constrains > so that for all { x, y: T ] 
implies Transitive with [ < for ® ], 
Transitive with [ > for ® ], 
Antisymmetric with [ < for ® ] 
Antisymmetric with [ > for ® ], 
PartialOrder with { > for < ] 
converts [<, >, > ] 
PartiallyOrdered: trait 
imports PartialOrderWithEquality 
includes DerivedOrders 
implies PartialOrderWithEquality with [ > for < ] 
Ordered: trait 


imports TotalOrderWithEquality 
includes DerivedOrders 
implies PartiallyOrdered, TotalOrderWithEquality with [ > for < ] 
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Group Theory 


Leftidentity: trait 
introduces 
#0O#:T,T?T 
unit: - T 
asserts for all { x: T ] unitO x = x 
RightIdentity: trait 
introduces 
#O#:T, TT 
unit: — T 
asserts for all [ x: T ] x O unit = x 
Identity: trait includes LeftIdentity, RightIdentity 
LeftInverse: trait 
assumes LeftIdentity 
introduces inv: T — T 
asserts for all [ x: T ] inv(x) O x = unit 
RightInverse: trait 
assumes Rightidentity 
introduces inv: T -> T 
asserts for all [ x: T ] x O inv(x) = unit 
Inverse: trait 


assumes Identity 
includes LeftInverse, RightInverse 


Abelian: trait imports Commutative with [ T for Range ] 
Semigroup: trait includes Associative, Equality 
Monoid: trait includes Semigroup, LeftIdentity 
Group: trait 
includes Monoid, LeftInverse 
implies RightIdentity, RightInverse 
AbelianSemigroup: trait includes Abelian, Semigroup 
AbelianMonoid: trait 
includes Abelian, Monoid 
implies RightIdentity 
AbelianGroup: trait includes Abelian, Group 
Distributive: trait 
introduces 
#+4:T,T oT 
#°*#:T,T >T 
asserts for all [ x, y, z- T } 
x*(y + 2) = (Py) + (x*2) 
(y + 2)*x = (y*x) + (27x) 
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Simple Numeric Types 


Ordinal: trait 
includes PartialOrder with [ = for .eq, Ord for T ], 
OrderEquivalence with [ = for .eq, Ord for T ] 
introduces 
first: -—»> Ord 
succ: Ord —> Ord 
asserts Ord generated by [ first, succ ] 
Ord partitioned by [ < ] 
for all [ x, y: Ord ] 
first < x 
~(succ(x) < first) 
succ{x) < succ(y) = x Sy 
implies TotalOrderWithEquality with [ Ord for T } 
converts [ <, = ] 
Cardinal: trait 
imports Ordinal with [ 0 for first, Card for Ord ] 
includes DerivedOrders with { Card for T ] 
introduces 
1: — Card 
#+#: Card, Card — Card 
#*#: Card, Card — Card 
#06 #: Card, Card -> Card 
constrains 1 so that 1 = succ(0) 
constrains +, * so that for all [ x, y: Card ] 
x+0=x%x 
x + succ(y) = succ(x + y) 
x*0 = 0 
x*suce(y) = x + (x*y) 
constrains © so that for all [ x, y: Card ] 
08x=0 
xOd=x 
succ(x) © succ(y) = x O y 
implies Cardinal2 
Card generated by [ 1, +, © ] 
Card partitioned by [ > ], by [ = ], by[ <], by[ >] 
for all [ x, y: Card] x < y = ((x © y) = 0) 
converts [ 1, 8, +, *, =, <, >. <, > ] 
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Cardinal2: trait % Alternate definition for comparison 


includes AbelianMonoid with [ + for O, 0 for unit, Card for T ], 
AbelianMonoid with [ * for O, 1 for unit, Card for T ], 
Distributive with [ Card for T ], 
Ordered with [ Card for T ] 
introduces 
#O#: Card, Card — Card 
succ: Card —» Card 
asserts Card generated by [ 0, 1, + ] 
for all [ x, y: Card ] 
x < (x + 1) 
(x+y Oy=x 
06x=0 
succ(x) = x + 1 
implies Cardinal 
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Simple Data Structures 


Pair: trait 
introduces 
<#, #>: T1,T2~ C 
#. first: C > Tl 


# second: C — T2 
asserts C generated by [<#, #> ] 
C partitioned by [ .first, second ] 
for all [ £ T1, s: T2 ] 
<f, s>.first = f 
<f, s>.second = s 
implies converts [ .first, second ] 
Triple: trait 
introduces 
<#, #, #>: T1, T2,T3 ~C 
# first: C — T1 
# second: C -> T2 
# third: C — T3 
asserts C generated by [<#, #, #>] 
C partitioned by [ .first, second, -third ] 
for all [ f: T1, s: T2, «: T3 J 


<f. s, O.first = f 
<f s, D.second = s 
<f, s, D.third = t 


implies converts { .first, .second, .third ] 
FiniteMapping: trait 
assumes Equality with [ Index for T ] 
introduces 
new: > C 
bind: C, Index, E ~ C 
#[#]: C, Index > E 
defined: C, Index -> Bool 
asserts C generated by [ new, bind ] 
C partitioned by [ #[#], defined ] 
constrains C so that 
for all [ c: C, i, iJ: Index, e: E ] 
bind(c, i/, ei] = if i = i] then e else c{iJ 
~defined(new, i) 
defined(bind(c, i/, e), ) = (i = il) | defined{c, i) 
implies converts [ #[#], defined ] 
exempts for all [ i: Index ] new(] 
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Container Properties 
Container: trait 
introduces 
new: > C 
insert: C, E —~ C 
asserts C generated by [ new, insert } 
Singleton: trait 
assumes Container 
introduces singleton: E — C 
constrains singleton so that for all [ e: E ] 
singleton{e) = insert(new, e) 
implies converts [ singleton } 
IsEmpty: trait 
assumes Container 
introduces isEmpty: C -> Bool 
asserts for all [ c: C, e: E ] 
isEmpty(new) 
~isEmpty(insert(c, )) 
implies converts { isEmpty } 
Size: trait 
assumes Container 
imports Cardinal 
introduces size: C —> Card 
constrains size so that 
size(new) = 0 
AdditiveSize: trait 


assumes Container 
includes Size 
constrains size, insert so that for all [{ c: C, e: E ] 
size(insert(c, e)) = size(c) + 1 
implies converts [ size ] 
Join: trait 
assumes Container 
introduces # join#: C,C + C 
constrains join so that for all [ c, c/: C, e: E] 
c join new =c 
c join insert(c/, e) = insert(c join c/, e) 
implies converts [ join ] 
ElementEquality: trait imports Equality with [ E for T ] 
Member: trait 
assumes Container, ElementEquality 
introduces #€#: E, C — Bool 
constrains €, insert so that for all [ c: C, e, e/: E] 
~(e € new) 
e € insert(c, e/) = (e = e/)|(e E c) 
implies converts [ € ] 
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ElemCount: trait 


assumes Container, ElementEquality 
imports Cardinal 
introduces count: C, E — Card 
constrains count, insert so that for all [ e, e/: E, c: C ] 
count(new, e) = 0 
count(insert(c, e), e/) = count(c, e) + (if e = ef then 1 else 0) 
implies converts [ count ] 


Delete: trait 


assumes Container 
introduces delete: C, E — C 
constrains delete so that for all { e: E ] delete(new, e) = new 


Containment: trait 


Next: 


assumes Container 
includes PartiallyOrdered with { C for <, D for >, C for <, > for >, C for T ] 


constrains C so that for all [ e: E, c: C ] c © insert(c, e) 
implies for all [ c: C ] new Cc 
trait 


assumes Container 

introduces next: C — E 

constrains next, insert so that for all [ e: E ] next(insert(new, e)) = e 
exempts next(new) 


Rest: trait 


assumes Container 

introduces rest: C > C 
constrains rest, insert so that for all [ e: E ] rest(insert(new, e)) = new 
exempts rest(new) 


Remainder: trait 


Index: 


assumes Container, Rest 

imports Cardinal 

introduces remainder: C, Card — C 

constrains remainder so that for all [ c: C, i: Card ] 
remainder(c, 0) = c 
remainder(c, i + 1) = remainder(rest(c), 1) 

implies converts { remainder ] 

trait 

assumes Container, Next, Rest 

imports Cardinal 

introduces #[4#]: C, Card > E 

constrains #[#] so that for all [ c: C, i: Card J 
e{1] = next(c) 
dCi + 1)] = rest(ch] 

implies converts [ #[#] ] 

exempts for all [ c: C ] c{0] 
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Container Classes 


SetBasics: trait 
assumes ElementEquality, Container with [ {} for new ] 
includes Size with [ {} for new ], 
Member with [ {} for new ] 
introduces delete: C, E —- C 
constrains C so that 
C partitioned by [ € ] 
for all [ s: C, ¢ ef: E] 
size(insert(s, e)) =size(s) + (if e € s then 0 else 1) 
el € delete(s, e) = (el € s) & (~(e = e/)) 
implies Delete with [ {} for new ] 
converts [ size, delete, € ] 
BagBasics: trait 
assumes ElementEquality, Container with [ {} for new ] 
imports AdditiveSize with [ {} for new ], 
ElemCount with [ {} for new ] 
includes Member with [ {} for new ] 
introduces delete: C, E —- C 
constrains C so that 
C partitioned by [ count ] 
for all [ 5: C, e e/: EJ 
count(delete(b, e), e/) = count(d, e/) — (if e = e/ then 1 else 0) 
implies Delete with [ {} for new ] 
converts [ size, delete, count, € ] 


CollectionExtensions: trait 


assumes ElementEquality, Container with [ {} for new ] 
imports IsEmpty with [ {} for new ], 
Singleton with [ {} for new, {#} for singleton ], 
Containment with [ {} for new ], 
Join with [ {} for new, U for join ] 
includes Equality with [ C for T ] 
implies converts [ {#}, isEmpty, U ] 


SetIntersection: trait 


assumes SetBasics 

introduces MN: C, C ~ C 

constrains C so that for all [ s s/:C, e e/: EJ 
e€ (sf sl) = (e € 5s) & (e € s/) 

converts [1M ] 

Set: trait 

assumes ElementEquality 

imports SetBasics, SetIntersection 

includes CollectionExtensions 

implies Abelian with [ U for O, C for T ], 
Abelian with [ for O, C for T ] 

converts [ size, delete, €, MN, U, {#}, isEmpty, =, C, D, C, D] 
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Bag: trait 

assumes ElementEquality 

imports BagBasics 

includes CollectionExtensions 

implies Abelian with [ U for O, C for T ] 

converts [ size, delete, count, €, U, {#}, isEmpty, =, C, D, €, 2] 
Enumerable: trait 


imports IsEmpty, Next, Rest 


includes Container 
constrains C so that C partitioned by [ next, rest, isEmpty |] 
InsertionOrdered: trait % For assuming “Stack or Queue” 


includes Enumerable 
introduces isFIFO: -> Bool 
constrains next, rest, insert so that for all [ c: C, e: E] 
next(insert(c, e)) = if isEmpty(c) | isFIFO then e else next(c) 
then 


rest(insert(c, e)) = if isEmpty(c) | isFIFO c else insert(rest(c), ¢) 
implies converts [ next, rest ] 
Stack: trait 
includes InsertionOrdered with [ push for insert, top for next, pop for rest, 
true for isFIFO ] 
implies for all [ stk: C, e: E ] 
top(push(stk, e)) = e 
pop(push(stk, ¢)) = stk 
Queue: trait 


includes InsertionOrdered with [ first for next, false for isFIFO ]. 
implies for all [ g: C, e: E ] 
first(insert(g, e)) = if isEmpty(g) then e else first(g) 
rest(insert(g, e)) = if isEmpty(q) then new else insert(rest(q), e) 


Dequeue: trait 


includes Stack with [ insert for push, first for top, rest for pop ], 
Stack with [ enter for push, last for top, prefix for pop ] 
constrains C so that for all [ c: C, e, e/: E] 
insert(new, e) = enter(new, e) 
insert(enter(c, e), e/) = enter(insert(c, e/), e) 
implies Queue, Queue with { enter for insert, last for first, prefix for rest ] 
converts [ insert, first, last, rest, prefix], [ enter, first, last, rest, prefix ] 
Sequence: trait 
imports Dequeue, AdditiveSize 
includes Index with [ first for next ], 
Join with [ || for join } 
implies C partitioned by [ size, #[#] ] 
SubSequence: trait 
imports Sequence 
includes Remainder with [ #[#...] for remainder ], 
Remainder with [ #[...4] for remainder, prefix for rest ] 


Sota MEME to 
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String: trait 
imports Character 
includes Sequence with [ length for size, Char for E } 
PriorityQueue: trait 
assumes TotalOrder with [ E for T ] 
includes Enumerable 
constrains next, rest, insert so that for all [ g: C, e: E ] 
next(insert(qg, e)) = if isEmpty(g) then ¢ 
else if next(q) < ¢ then next(g) else ¢ 
rest(insert(g, e)) = if isEmpty(g) then new 
else if next(q) < ¢ then insert(rest(g), ¢) else ¢ 
implies converts [ next, rest, isEmpty ] 


Generic Operators on Containers 


CoerceContainer: trait 


assumes Container with [ DC for C ], 
Container with [ RC for C ] 
introduces coerce: DC -» RC 
constrains coerce so that for all [ dc: DC, e: E } 
coerce(new) = new 
coerce(insert(dc, e)) = insert(coerce(dc), e) 
implies converts [ coerce ] 
Reduce: trait 
assumes Enumerable, 
Rightidentity with [ E for T ], 
Associative with [ E for T ] 
introduces reduce: C — E 
constrains reduce so that for all [ c: C ] 
reduce(c) = if isEmpty(c) then unit else next(c) O reduce(rest(c)) 
implies converts [ reduce ] 


SomePass: trait 


assumes Container 
introduces 
test: E, T — Bool 
somePass: C, T — Bool 
constrains somePass so that for all [ c: C, e: E, «: T] 
~somePass(new, 1) 
somePass(insert(c, e), 1) = test(e, | somePass(c, 
implies converts [ somePass ] 
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AllPass: trait 


assumes Container 
introduces 
test: E, T — Bool 
allPass: C, T — Bool 
constrains allPass so that for all [ c: C, ee: ET] 


allPass(new, £) 
allPass(insert(c, e), 2) = test(e, ) & allPass(c, i) 
implies converts [ allPass ] 
Sift: trait 
assumes Container 
introduces 
test: E, T — Bool 
sift: C, T— C 


constrains sift so that for all [ c: C, e: E, « T ] 
sift(new, ) = new 
sift(insert(c, e), ) = if test(e, #) then insert(sift(c, t), e) else sift(c, 
implies converts [ sift } 
PairwiseExtension: trait 
assumes InsertionOrdered 
introduces 
extOp: C,C ~C 
elemOp: E, E> E 
constrains extOp so that for all [ c/, c2: C, el, e2: E] 
extOp(new, new) = new 
extOp(insert(c/, e/), insert(c2, e2)) = insert(extOp(c/, c2), elemOp(e/, €2)) 
implies converts [ extOp ] 
exempts for all [ c: C, e E] 
extOp(new, insert(c, e)), 
extOp(insert(c, e), new) 
PointwiseImage: trait 
assumes Container with [ DC for C, DE for E ], 
Container with [ RC for C, RE for E ] 
introduces 
extOp: DC — RC 
pointOp: DE — RE 
constrains extOp so that for all [ de: DC, de: DE } 
extOp(new) = new 
extOp(insert(dc, de)) = insert(extOp(dc), pointOp(de)) 
implies converts [{ extOp ] 
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Nonlinear Structures 


BinaryTree: trait 
imports Cardinal 
introduces 
<#>:E-~C 
<#, #>:C,C7>C 
# left: C - C 
# right: C + C 
size: C — Card 
isLeaf: C-» Bool 
content: C ~ E 
constrains C so that 
C generated by [<#>, <#, #>] 
C partitioned by [ .left, .right, content, isLeaf ] 
for all [ ¢, tr: C, e: E] 
(<a, tr>)Jeft = il 
(<i, tr>).right = Ir 
size(<e>) = 1 
size(<i, tr>) = size(tl + size(tr) 
isLeaf{<e) 
~isLeaf{<il, tr) 
content(<e) = e 
implies for all [ t: C ] isLeaf{s) = (size() = 1) 
converts [ .left, .right, size, isLeaf, content ] 
exempts for all [ 7, tr: C, e: E ] (<e>).left, (<e>).right, content(<é/, tr>) 
BasicGraph: trait 
assumes Equality with [ Node for T ] 
imports Set with [ NodeSet for C, Node for E ], 
Pair with [ Edge for C, Node for Tl, Node for T2 ] 
introduces 
empty: ~—> Graph 
addNode: Graph, Node -* Graph 
addEdge: Graph, Edge -> Graph 
nodes: Graph —> NodeSet 
adj: Node, Graph -> NodeSet 
constrains Graph so that 
Graph generated by [ empty, addNode, addEdge ] 
Graph partitioned by [ nodes, adj ] 
for all [ g: Graph, e: Edge, n, n/: Node } 
nodes(empty) = {} 
nodes(addNode(g, n)) = insert(nodes(g), 7) 
nodes(addEdge(g, ¢)) = insert(insert(nodes(g), e.first), e.second) 
adj(n, empty) = {} 
adj(n, addNode(g n/)) = adj(n, g) 
adj(n, addEdge(g, ¢)) = 
if n = (e.first) then insert(adj(n, g), e.second) else adj(n, g) 
implies converts [ nodes, adj ] 
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Connectivity: trait 


assumes Equality with [ Node for T ], BasicGraph 
introduces 
reach: NodeSet, Graph —> NodeSet 
allReach: NodeSet, NodeSet, Graph -> Bool 
connected: Graph -» Bool 
constrains reach, allReach, connected so that 
for all [ g- Graph, e: Edge, ns, ns/: NodeSet, n: Node ] 
reach(ns, empty) = {} 
reach(ns, addNode(g, n)) = reach(ns, g) 
allReach{{}, ns, g) 
allReach(insert(ns, n), ns/, g) = 
allReach(ns, ns/, g) & (nsi © reach({n}, g)) 
connected(g) = allReach(nodes(g), nodes(g), g) 
implies converts { allReach, connected ] 


Graph: trait 


assumes Equality with [ Node for T ] 
imports BasicGraph 
includes Connectivity, 
Connectivity with [ stronglyConnected for connected, pathReach for reach, 
allPathReach for allReach } 
constrains reach, allReach, connected so that 
for all [ g: Graph, e: Edge, ns: NodeSet ] 
reach(ns, addEdge(g, e)) = reach(ns, g) U 
(if (e.first) € ns then insert(reach({(e.second)}, g), (e.second)) 
else if (e.second) € ns then insert(reach({(e.first)}, g), (e.first)) 
else {}) 
constrains pathReach, allPathReach, stronglyConnected so that 
for all [ g: Graph, e: Edge, ns: NodeSet ] 
pathReach(ns, addEdge(g, e)) = pathReach(ns, g) U 
(if (e.first) € ns 
then insert(pathReach({(e.second)}, g), (esecond)) 
else {}) 
implies converts [ reach, allReach, connected, pathReach, allPathReach, 
stronglyConnected ]} 
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Rings, Fields, and Numbers 


Ring: trait 
includes AbelianGroup with [ + for O, 0 for unit, — # for inv }, 
Semigroup with [ * for O J, 
Distributive 
RingWithUnit: trait 
includes Ring, Identity with [ * for O, 1 for unit ] 
InfixInverse: trait 
assumes Inverse 
introduces #@ #: T, T -»> T 
constrains #@# so that for all [ x, y: T ] 
x@y= xO inv(y) 
implies converts [ #@ # ] 
Integer: trait 
includes RingWithUnit with [ Int for T ], 
Ordered with [ Int for T ], 
InfixInverse with { + for O, — # for inv, — for @, Int for T ] 
asserts Int generated by [ 1, +, — # ] 
for all [ x: Int ] 
x<(x+ 1) 


implies Rational without [ “!, / ] with [ Int for R ] 
converts [ 0, *, #-#, =, <<, >.<, >] 

Field: trait 
includes RingWithUnit 


introduces #1: T — T 
constrains *, “! so that for all [ x: T ] 
(x = 0) | (x(x) = 1) 
exempts 0! 
Rational: trait 
includes Field with { R for T ], 
Ordered with [ R for T ], 
InfixInverse with [ + for O, — # for inv, — for @, R for T }, 
InfixInverse with [ * for O, "#71 for inv, / for Q, R for T ] 
asserts 
R generated by[ 1, +. —#, 1] 
for all [x y, 27 RJ 


0<1 
en New ES z)) = (x ies y) 
= OG ” =(0< 2. 
implies mate [ 0, *, #- =<42,<>] 
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Lattices 


ExtremalBound: trait 
assumes PartialOrder 
includes AbelianSemigroup with [ .glb for O ] 
constrains .glb so that for all [ x, y, z: T ] 
(x .glb y) < x 
((z $ x) & (z < y))=>(z < (x gb y) 
Semilattice: trait 
includes PartiallyOrdered, 
ExtremalBound, 
ExtremalBound with [ > for <, -lub for .gib ] 
introduces L: -—> T 
constrains -L so that for all [ x: T ] 
x24 
implies AbelianMonoid with [ L for unit, Jub for O } 
Lattice: trait 
includes Semilattice 
introduces T: —> T 
constrains T so that for all { x: T ] 
x<T 
implies Lattice with [ T for L, 1 for T, .glb for lub, .lub for .glb, 
>for <, < for >, > for <, < for > ] 
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Enumerated Data Types 


Enumerated: trait 
imports Ordinal 
includes Ordered 
introduces 
first: — T 
last: — T 
succ: T > T 
pred: T — T 
ord: T — Ord 
asserts T generated by [ first, succ ] 
T partitioned by [ ord ] 
for all [ x, y: T ] 
ord(first) = first 
ord(succ({x)) = if x = last then ord(last) else succ(ord(x)) 
pred(succ(x)) = if x = last then pred(last) else x 
x Sy = ord(x) < ord(y) 
implies T generated by [ last, pred } 
for all [ x: T ] 
succ(pred(x)) = if x = first then succ(first) else x 
first < x 
x < last 
converts [ =, <, >, <, > ] 
Rainbow: trait 
includes Enumerated with [ Color for T ] 
introduces 
red: —» Color 
orange: — Color 
yellow: -—» Color 
green: —» Color 
blue: — Color 
violet: —»> Color 
asserts 


Color generated by [ red, orange, yellow, green, blue, violet ] 
first = red 
last = violet 


succ(red) = orange 
succ(orange) = yellow 
succ(yellow) = green 
succ{green) = blue 
succ(blue) = violet 
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implies converts [ pred, last, ord, =, <, >, <, >, red, orange, yellow, green, blue, 


violet ], 


[ succ, first, ord, =, <, >, <, >, red, orange, yellow, green, blue, violet ] 


Character: trait includes Enumerated with [ Char for T ] 


% For each programming language there will be mappings from character and string constants to 


% terms in the shared language. Because of the variety of character orderings and notations for 
% constants, these definitions are not likely to be portable across programming languages. 
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Display Traits 


% The following traits represent a fairly straightforward translation of the specificatiqns in 
% “Formal Specification as a Design Tool” (CSL-80-1). We have not attempted to improve the 
% a presented there, merely to translate it into Larch. 
Coordinate: trait introduces minus: Coordinate, Coordinate -» Coordinate 
Ilumination: trait introduces combine: Illumination, Illumination — Illumination 
Boundary: trait introduces apply: Boundary, Coordinate -> Bool 
Transform: trait introduces apply: Transformation, Coordinate —»> Coordinate 
Displayable: trait 
introduces 
appearance: T, Coordinate —> Illumination 
in: T, Coordinate —> Bool 
Picture: trait 
assumes Boundary, Transform, Ilumination, 
Displayable with [ Contents for T ] 
includes Displayabie with [ Picture for T ] 
introduces makePicture: Contents, Boundary, Transformation — Picture 
constrains Picture so that 
Picture generated by [ makePicture ] 
for all [ cn: Contents, b: Boundary, 1: Transformation, cd: Coordinate ] 
appearance(makePicture(cn, b, 2), cd) = 
appearance(cn, apply(7, cd)) 
in(makePicture(cn, 5, 1), cd) = apply(b, cd) 
implies converts [ appearance: Picture, Coordinate —> Illumination, 
in: Picture, Coordinate — Bool ] 


Contents: trait 


assumes Coordinate, Illumination, Displayable with [ Component for T ] 
includes Displayable with [ Contents for T } 
introduces 
empty: —> Contents 
addComponent: Contents, Component, Coordinate — Contents 
constrains Contents so that 
Contents generated by [ empty, addComponent ] 
for all [ cn: Contents, cm: Component, cd, cd/: Coordinate ] 
appearance(addComponent(cn, cm, cdl), cd) = 
if in(cm, minus(cd, cd!)) 
then (if in(cn, cd) 
then combine(appearance(cm, minus(cd, cd/)), 
appearance(cn, cd)) 
else appearance(cm, minus(cd, cd/))) 
else appearance(cn, cd) 
~in(empty, cd) 
in(addComponent(cn, cm, cd/), cd) = 
in(cm, minus(cd, cd/)) | in(cn, cd) 
implies converts [ appearance: Contents, Coordinate — Illumination, 
in: Contents, Coordinate —> Bool ] 
exempts for all [ cd: Coordinate ] appearance(empty, cd) 
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Component: trait 
assumes Displayable with [ View for T ], 
Displayable with [ Text for T ], 
Displayable with [ Figure for T ] 
includes ComponentCoercion with [ View for T, coerceView for coerce}, 
ComponentCoercion with [ Text for T, coerceText for coerce ], 
ComponentCoercion with [ Figure for T, coerceFigure for coerce ] 
ComponentCoercion: trait 
assumes Displayable 
includes Displayable with [ Component for T ] 
introduces coerce: T -> Component 
constrains Component so that fer all [ «: T, cd: Coordinate | 
appearance(coerce(/), cd) = appearance(!, cd) 
in(coerce(?), cd) = in(t, cd) 
View: trait 
assumes Displayable with [ Picture for T ], 
Equality with [ Pictureld for T ], 
Container with [ IdList for C, Pictureld for E ], 
Coordinate 
includes Displayable with [ View for T ] 
introduces 
empty: — View 
addPicture: View, Coordinate, Pictureld, Picture — View 
findPictures: View, Coordinate —> IdList 
deletePicture: View, Pictureld — View 
constrains View so that 
View generated by [ empty, addPicture ] 
for all [ v- View, cd, cdi: Coordinate, id, id/: Pictureld, p: Picture } 
appearance(addPicture(v, cd/, id, p), cd) = 
if in(p, minus(cd, cd/)) then appearance(p, minus(cd, cd/)) 
else appearance(v, cd) 
~in(empty, cd) 
in(addPicture(v, cd/, id, p), cd) = (in(p, minus(ed, cd/)) | in(v, cd)) 
findPictures(empty, cd) = new 
findPictures(addPicture(v, cd/, id, p), cd) = 
if in(p, minus(cd, cd/)) then insert(id, findPictures(v, cd)) 
else findPictures(v, cd) 
deletePicture(empty, id) = empty 
deletePicture(addPicture(v, cdl, idl, p), id) = 
if id .eq id/ then v else addPicture(deletePicture(v, id), cd, id/, p) 
implies converts [ findPictures, deletePicture, 
appearance: View, Coordinate —> [llumination, 
in: View, Coordinate -» Bool ] 
exempts for all [ cd: Coordinate ] appearance(empty, cd) 
Display: trait 
assumes Boundary, Transform, Illumination, Coordinate, 
Equality with [ Pictureld for T ], 
Container with [ IdList for C, Pictureld for E ] 
includes Picture, Contents, Component, View 
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